terraform: catch scenario where both "foo" and "foo.0" are in state #1086
Conversation
|
|
||
| resource "aws_instance" "bar" { | ||
| foo = "bar" | ||
| } |
There was a problem hiding this comment.
Removed this since we weren't using it in the test.
|
thanks @mitchellh, trying this out now |
|
@mitchellh orphan nodes do get removed from state, however some dependent entities (i.e. Another question, if an entity supporting I hope I've understood the PR correctly and making a bit of sense. Still early here, on my first coffee still. |
|
@pmoust The case of increasing/decreasing counts is very heavily tested. (From no count, to X count, to 1 count, to X-prime, etc.). In your case, the |
terraform: catch scenario where both "foo" and "foo.0" are in state
|
@mitchellh thanks for the quick action on the patch and the walkthrough, man! |
|
No problem, thanks for the great bug reports. :) |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Fixes #1047 (cc @pmoust)
I'm not sure what caused this, but it seems that there is a possibility in the state to have both a
type.nameandtype.name.0to be present. If both of these are present, we experience some very bizarre behavior. In 0.3.7 and prior, it appears we just assumetype.nameis the valid resource to use, and thetype.name.0value is completely ignored. There seems to be no way to do anything with it (including remove it) short of modifying the state.This PR causes the
type.name.0to behave as an orphan in the case both are present andcount = 1. While in theory it is possible that either are the one you want, I think in practice we should remove the.0resource because it appears that this is how 0.3.7 behaved by completely ignoring it (therefore not destroying it but also not using its values for any dependent resources).The fix here is pretty simple:
PruneDestroyTransform, we must not prune the destroy node if we see this scenario.FixZeroOneBoundaryeval node, we must not override and therefore mask the value if we see that both the hunt and replace exist. This will cause both to remain and the orphan transform to pick it up later.I don't think its possible going currently in master and going forward to ever persist a state with both, so this situation must be a backwards compat possibility.
To be clear, here is the before/after:
type.name.0value is always completely ignored. It is not treated as an orphan, attributes are not reference-able, it is in the state but never affects plans/applies in any way. It is as if it isn't there.type.name.0value is always used, andtype.nameis completely ignored. The inverse of 0.3.7 and before. But likewise,type.nameis therefore never fixable.type.name.0is treated as an orphan,type.nameis used. We chose this route because 0.3.7 usetype.nameso we should use those values for BC reasons.